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• David Schuetz 

• Senior Security Consultant at Intrepidus Group 

• iOS app security, web app testing, etc. 

• Crypto puzzle geek (frequent winner and author) 

• Spent years as a government contractor 

• Sometimes a little more risk-averse that most 
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Introduction 
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Applications! p arto,nccarou p 

• Millions of apps available in iOS App Store 

• Many (most?) of them are completely standalone 

• Photo editors, games, calculators 

• Many access sensitive information over the net 

• Banks 

• Health care 

• Work related 

• Most of these will have web-based interfaces as well 

• Often with features beyond mobile apps 

• Credentials stolen from mobile may be useful there 
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Backdoor via weak authentication p arto,ncc9rou p 

• Lost phone, left unlocked: 

• May be able to directly extract credentials 

• Configure a proxy and intercept credentials 

• If jailbroken... .jackpot! 

• Even if not lost or stolen: 

• May be able to MITM using public Wi-Fi 

• Question: How exposed are most apps? 


Related: How are apps authenticating today, generally? 
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Authentication Survey p arto,nccarou p 

• General assessment of a single security vector 


• Select a cross-section of iOS applications 

• How do these applications authenticate? 

• Do they do anything insecurely? 

• Could they do anything better? 

• Anything exceptional (good or bad)? 
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Selecting Applications 


My iPhone 
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• On my fourth iPhone in 6 years 

• Accumulated many, many applications 

• Over 230 actually installed on phone today 

• (not even thinking about those I've deleted) 

• Should be a pretty representative sampling of apps 


However: this means it's sort-of self-selected 
• So not really "pure" from a research standpoint 
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Dropping from the list apps which: p ‘* o,noco,DMP 

• Have no obvious network services (100+ apps) 

• Use only OS-managed services (like iCIoud calendar) 

• Use only 3rd party services (game tweeting scores) 

• Only local network services (like SSH orVNC) 

• Anonymous services (no userid) 

• Those I don't actually have logins for 

• Anything no longer in the app store 
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Applications remaining p arto,nccarou p 

• Nearly 50 applications 

• Of these, seven couldn't be intercepted 

• Ignored proxy settings 

• Limited time meant I couldn't dig deeper 

• Actually looked at 40 apps, including: 

• Banking 

• Healthcare 

• Travel 

• Cloud storage 

• Social networking 
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Which applications? p arto,nccarou p 

• Not gonna tell ya. (Ha, ha!) 

• Won't endorse (or condemn) any individual app 

• Very narrow assessment focus 

• Didn't look for bugs or weaknesses 

• High level survey 

• Only spent an hour or less per app 

• Deep dives would take much longer 
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Workflow 


intrepidusgroup® 

part of nccgroup 



13 


intrepidusgroup® 

Made four passes parto,nccoroup 

• Using MITM proxy with untrusted root certificate 

• See whether apps even notice 

• Most actually did 

• Using MITM proxy with trusted cert 

• See whether a forged cert works 

• Most of the time, it did 

• Bulk of work happened here 

• Re-launched all apps days later 

• Final verification and loose ends 

• Also re-launched with missing CA cert 
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Looking for... parto,nccoroup 

• Initial authentication 

• How are credentials passed? 

• Continued (session) authentication 

• Credentials passed each time, or are tokens used? 

• Renewed authentication 

• Can app automatically login after being quit? 

• Credential storage 

• Is password stored, or just a token? 

• Is anything stored insecurely? 
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High-level review targets p arto,nccorou p 

• Put another way, we want to verify: 

• Secure Network 

• Secure Login 

• Secure Session 

• Secure Storage 
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Not looking for p arto,nccorou p 

• Specific security flaws 

• Though I found a few weaknesses 

• Including Pll enumeration using email addresses 

• Server-side issues 

• Security of the application itself 

• Didn't reverse-engineer, disassemble, etc. 

• Not nearly enough time 

• Only two apps dropped because of complexity 

• Didn't look at additional "followup" authentication 

• Like asking your password before a purchase 
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Ideas for future talks 
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• Third-party (4th party?) services 

• Analytics providers: Crashlytics, Flurry, Hockey, etc. 

• Many supported one or more of these 

• What data is being sent? How detailed? Is it secure? 


• General application security 

• Unsafe data storage 

• Use (or lack) of data protection / file encryption 

• Sensitive data leakage in cache, logs, crash data, etc. 
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General process p arto,nccorou p 

• Jailbroken iPhone 5C running iOS 8.1.2 

• Installed all apps from app store 

• Only one app already on phone, so all rest are "fresh" 

• Monitor /var/log/syslog 

• Intercept traffic using Burp Suite 

• Launch application, monitor login process 

• Wanderthrough app, monitor continuing session auth 

• Kill app, launch again, observe re-login process 

• Review keychain for new entries 

• Copy sandbox off device and review data storage 
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Findings 
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Review Target: Secure Network p arto,nccorou p 

• Credential-stealing attacks: 

• Public wifi, attacker MITMs connection 

• Unlocked device, attacker installs proxy + cert 

• Good design: 

• UseTLS (No, seriously, use it) 

• If cert is untrusted, refuse connection 

• Blocks naive MITM 

• If possible, refuse if cert is unknown: PIN CERT 

• Blocks MITM with trusted but malicious cert 
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Why isTLS so important? 

• Most authentication methods absolutely rely upon it 

• TLS compromise ==You Win (something) 

u The majority of developers' confusion and annoyance with OAuth 
1.0 was due to the cryptographic requirements of signing requests 
with the client ID and secret. Losing the ability to easily copy and 
paste cURL examples made it much more difficult to get started 
quickly. 

OAuth 2 recognizes this difficulty and replaces signatures with 
requiring HTTPS for all communications between browsers, clients 
and the API." 

— u OAuth 2 Simplified", aaronparecki.com 
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This bears repeating parto,ncc9r0 '* 

• Dynamic tokens "confuse developers" 

• So we'll rely on TLS 

• TLS security far from guaranteed 

• CA compromise 

• OpenSSL bugs 

• Forced proxy use (work, school, airplane) 

• I think the opposite stance is required: 

• Use TLS, but don't rely on it 

• Assume your communications can be intercepted 
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First pass: No CA certificate par,o, n cc 9 rou P 

• Of forty applications tested: 

• 38 failed with some kind of error 

• One didn't care 

• One didn't notice because it didn't useTLS 


• Terrible user experience 


Error Message Displayed 

General "network error" message 

14 


General "proxy error" message 

7 


Generic error (like "try again later") 

6 


"Check Credentials" 

6 


NSURLErrorDomain -1012 

4 


Helpful and accurate message 

1 
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Great error messages parto,nccoroup 

• "Network connectivity may be poor" 

• "Oops! Thanks for your patience while we get it fixed. 
Looks like something was left unplugged." 

• "Oops! We're currently experiencing a number of 
technical difficulties within our app. We are actively 
working to resolve these issues and return the app to 
full functionality as soon as possible. Thank you for 
your patience." 
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One of these is not like the others 
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Error Searching 

The operation couldn’t be completed. 
(NSURLErrorDomain error -1012.) 


Error 

Login failed. Please check credentials. 



OK 


Network Err 


Connection Timeout 

The URL connection timed out. 


There was a problem communicating 
with the secure web proxy server 
(HTTPS). 


Continue 



Sorry, it looks like something went 

wrong 


System Error 

We’re not able to process your reque 
at this time. Please try again later. 


Connection Security Error 

Cannot establish a secure sync 
connection. Please update the app or 
check Overcast.fm for updates. 

To protect your password, data, and 
privacy, Overcast refuses to connect 
with reduced security. 


OK 


Best error message 
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Connection Security Error 

Cannot establish a secure sync 
connection. Please update the app or 
check Overcast. fm for updates. 

To protect your password, data, and 
privacy, Overcast refuses to connect 
with reduced security. 


OK 
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Best LOL: It's a podcast app! p ‘" ofnoeB " up 

•••oo Virgin ^ 11:01 AM -f $ 

% lJ + 


PLAYLISTS 


All Episodes 


Connection Security Error 

Cannot establish a secure sync 
connection. Please update the app or 
check Overcast. fm for updates. 

To protect your password, data, and 
privacy, Overcast refuses to connect 
with reduced security. 


1 


IN 



OK 


BILL BRENNER 


The Incomparable (plus Bonus 
Tracks) 

JASON SNELL 


LAST SYNC FAILED 
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Second pass: Installed Burp cert p 0 ™ 0 ™* 

• Of 38 apps remaining: 

• 34 applications worked fine 

• Two applications appeared to be pinned 

• But I bypassed using Snoop-lt 

• One appeared pinned (and couldn't be bypassed) 

• One appeared pinned and may even be cert based: 

• "Missing authentication credentials [cert]" 

• Able to continue analysis with 36 apps 

• (plus two from before, so 38 total) 
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Review Target: Secure Login parto,nccoroup 

• Attacker: 

• Circumvents one or more controls 

• Steals password from network 

• Reuses password elsewhere (web interface) 

• Good design: 

• Never store or send password 

• Store some kind of hash or refresh token 
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Initial authentication p arto,ncc9rou p 

• Most passed "plaintext" userid and password 

• Vast majority via data in the POST body 

• A handful via HTTP headers 

• Two were not even base-64 encoded 

• Two sent credentials as part of the URL 

• One had userid, MD5(password) 

• One had human-readable plaintext 

• Some passed secondary credentials over POST 

• Answer to security question 

• 2-step verification PIN 


Many data formats 
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username= — redacted — &passwd= — redacted — &signin=&_ts= 
1419965597&_tpa=&_muh=6,_crumb=EIyLUJDQzUt&_uuid=0DhEQT 
QzN&_seqid=l 


<?xml version="1.0" encoding="ut 
<authenticateRequest xmlns= M — re 
<c redent ials> 

<userld> — redacted— </us 
<password> — redacted— </. 

<f o rmat>USERNAME_OR_EMAIL</fon 
</c redent ials> 

<options> 

<tokenType>SHORT</tokenType> 

<responseProperties> 

<property name="actorId"/> 
</responseProperties> 
</options> 

</authenticateRequest> 


{"Passwo rd" : " — redacted — " , "UserName" : " — redacted 
Consume rKey" : "238FDB93-C482-4BE0-BD81-280DBA54C7B5"} 


II II 
I 


GET /index. php?userLogin= — redacted — &md5Password= — re 
dacted — &module=API&date=today&token_auth=anonymous&pe 
riod=day&format=json&method=UsersManager.getTokenAuth& 
language=en& HTTP/1.1 


Authorization: OAuth realm= M ", oauth_consumer_key="ae5 
56al3475d7c2cfe7ac7d24de376749db59282", oauth.signatur 
e_method="HMAC-SHAl" , oauth_signature="upbbcCDYUZ4B2YD 
394zahjez5%2B4%3D" , oauth_timestamp=" 1420209957", oaut 
h_nonce="2DC17E71-921E-4723-9123-2BE55233DD0A" , oauth_ 
version="1.0'’, xoauth_username=" — redacted — xoauth_ 
passwo rd=" — redacted — " 


POST /login HTTP/1.1 
username: — redacted — 
password: — redacted — 

Content-Type: application/x-www-form-urlencoded 
^ ^ * |th: 0 

icted — 
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, r , , , , intrepidusgroup® 

Obfuscated credentials (beyond B64) p arto,nccorou p 

• Encryption 

• Binary data structure 

• GZip compression 

• Only about five apps total 


33 


intrepidusgroup® 

Cool methods partof nccqroup 

• Encrypted password 

• App sends userid, server responds with key 

• App encrypts password with this key and submits 

• An attacker with just the one packet is out of luck 

• Of course, if they saw the key... 

• Full encryption 

• Two appeared encrypted (not positive) 

• Another sent a private key upon login 

• All subsequent traffic included signature 
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Dumb behavior parto,nccoroup 

• Autocorrect in the username field 

• Type in your account correctly: 

• It's close to an English word 

• You tap to the password field 

• The phone "helps" you by correcting your userid 

• Why?!? 

• One app took me like 5 tries to notice 
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Review Target: Secure Sessions p arto,nccorou p 

• Attacker (avoiding previous controls) 

• Can steal tokens and use elsewhere 

• Good design: 

• Revocable token — user can de-authorize device 

• Use a dynamic token 

• Prevents replay attacks 

• However, attacker could return error, then use token 

• Use signatures 

• Request can't be altered 

• Also prevents transfer of unused tokens (as above) 
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Continued authentication p arto,nccorou p 

• How are requests authenticated as the app is used? 

• Two sent password with every request 

• Most sent some kind of token 

• Many some kind of OAuth variant 

• Tokens passed in a variety of locations: 

• URL parameters 

• Cookies 

• Authentication: or custom HTTP headers 

• POST request body 
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Interesting tokens p arto,nccorou p 

• Most tokens decoded to meaningless binary 

• A couple decoded to ASCII text 

• One: 

• Base64(<client id>:<uid>:<?>:i:<timestamp>:o— <?>) 

• The last block was 16 bytes, possibly an MD5 hash? 

• Might be able to brute force a server secret. Maybe. 
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Renewed authentication p arto,nccorou p 

• Force-quit each app then re-launched it 

• A few sent the userid and password again 

• A few asked the user to re-enter some credentials 

• Most sent a stored token 

• Didn't test token expiration times 

• Almost all stored some credentials 

• What were they? 

• And how were they stored? 


39 


, intrepidusgroup® 

Cool method partof nccqroup 

• Stores userid, encrypted with a server-side key 

• Client never sees the key 

• Client keeps partially readable name ("MyAcc***") 

• When logging in, app sends encrypted userid 

• Then asks for password 
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Review Target: Secure Storage p arto,nccorou p 

• Attacks 

• Unlocked device 

• Attach via USB 

• Directly access files in application sandboxes 

• Extract credentials that way 

• Use the keychain — it's designed for this 

• Absolutely password and tokens 

• If possible, store the userid here as well 
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Keychain storage p arto,nccorou p 

• Most secure location for storing sensitive data 

• Hard to extract: 

• Need a jailbroken device 

• Or the iTunes backup password 

• Found 8 usernames, 17 tokens, and 4 passwords 

• Also found lots of other information: 

• Some preference settings 

• Push tokens 

• Credentials for 3rd party services (twitter, etc.) 
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Less safe storage partof nccqroup 

• Preferences file (just a property list, not encrypted) 

• Almost half stored the username here 

• One included the user's password 

• HTTP cache (URLs, some other header & POST data) 

• Eleven had a password or token 

• Cookies file (Cookies) 

• Only a handful of userids and tokens 

• Other files and caches in /Library and /Documents 

• Including tokens and even one password 
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Third and fourth passes 
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• Third pass — renewed authentication (days later) 

• Launched all 38 apps again 

• Intercepted and reviewed login 

• No significant changes from first testing 

• Mostly verifying the previous findings 

• Fourth pass — MITM again, with no CA 

• All behaved as before: TLS errors 

• Some seemed to work, using local data 

• But failed when accessing the network 

• Need to check the certificate at all times 
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Summary of Findings 
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Handling of TLS Certificates 

Refused to work with bad MITM cert 

34 

Didn't care about bad MITM cert 

1 

Didn't notice bad cert because it used HTTP 

i 

Refused to use trusted MITM cert (pinning) 

4 


"LS Certificates 
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Initial Authentication 
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Initial login credentials sent via: 

Plaintext POST parameters 

25 

Obfuscated (but decipherable) POST parameters 

1 

Obfuscated (possibly encrypted) POST parameters 

2 

URL Parameters 

2 

HTTP Headers 

7 
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Continuing authentication 
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Continuous session authentication via: 1 

Re-sending userid / password credentials 

2 

Dynamic tokens (OAuth i.o # PKI # etc.) 

7 

Fixed tokens (long- or short-lived) 

28 


Session credentials sent via: 

URL parameters 

9 

POST body 

5 

HTTP headers 

24 
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Renewed authentication 
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After quitting and restarting the application, the app: 

Re-sends userid and password 

4 

Sends stored token 

28 

Asks user for password 

5 

Asks user for both userid and password 

1 
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Local credential storage 
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Location 

Userid 

Password 

Session Tokens 

Keychain 

11 

5 

14 

Preferences 

14 

1 

5 

Cookie File 

3 

1 

5 

HTTP Cache 

9 

2 

9 

/Documents 

11 

0 

4 

Other /Library 

3 

0 

4 


Six apps stored no passwords or tokens at all 
Passwords split between filesystem and keychain 
More tokens found on filesystem than in keychain 
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Cool things 
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Applications which included: 

Userid 

Great (and mostly accurate) TLS warning 

1 

Encrypted userid storage 

1 

Encrypted password delivery 

1+ 

Totally encrypted data 

i or 2 

Certificate based session 

i or 2 



Suggestions 
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Good Ideas partof nccqroup 

• Better storage and leak management 

• Store everything in the keychain 

• Work to avoid leakage to cache files 

• Unique tokens for session and renewed authentication 

• Advantages: 

• Can't easily extract credentials from unlocked device 

• User can revoke device tokens from website 

• Disadvantages: 

• Initial authentication can still be intercepted 

• Session tokens can be intercepted and reused 
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Better 
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• Store only a hash of the password 

• HASH( HASH(password) + nonce + timestamp) ) 

• Server refuses old tokens and re-used nonces 

• Refresh token regularly (weekly, or even daily) 

• Advantages: 

• Actual password never sent over network 

• If token is compromised, automatically expires quickly 

• Disadvantages: 

• Attacker can intercept request & return error to app 

• Use valid token with new request (password reset?) 
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Best part of nccgroup 

• All packets get "one time" token 

• HASH( HASH(pw) + nonce + timestamp + HASH(req) ) 

• Send userid, overall hash, nonce, timestamp 

• Strengths: 

• Authentication tokens can't be reused 

• Can't modify or forge requests using unused tokens 

• Weaknesses: 

• More complicated 

• Server needs to remember recent nonces 
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Above and Beyond parto,nccaroup 

• Use one-time tokens (as above) 

• Encrypt all requests with public key for server 

• Optionally, sign everything with client key 

• Should be damned near impossible to intercept 

• Extraction of hash from keychain remains a risk 

• For highest security, don't even store hash 

• User enters password with each new application 
launch 


Weak links remain 
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• If you make the mobile app unbreakable... 

• ....attackers will focus on browser- based interface 

• Much harder to add these features to web apps 
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Existing specifications p arto,nccorou p 

• OASIS /SAML 

• Timestamp, nonce, password hash, request hash 

• Only ever seen this once (on a customer's app) 

• Concept is simple, spec is complex and probably scary 

• OAuth 1.0 

• Also supports signed, authenticated requests 

• Developers thought it was too complicated 

• OAuth 2.0 

• Greatly simplified - easier to implement 

• Doesn't have as many features - not as strong 
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Conclusion 
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General conclusion 
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• Generally, the apps I tested were: 

x Excellent 
x Pretty good 

/Not bad, but could be better 
x Scare the hell out of me 


• Of 38 apps which completed review 

• 12 had only minor issues 

• 6 had at least one major issue 

• ZERO had no issues at all 

• A few simple fixes could kick most up a level 
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Overall Scores? 
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• Again, not a complete assessment so not entirely fair 

• If I had to categorize biggest issues seen: 


Severity 

Description 


Low 

Userid stored insecurely 

27 

Application does not use certificate pinning 

36 


Credentials or tokens passed as URL parameters 

9 

Medium 

Tokens Stored Insecurely 

21 


Application sends credentials for every request 

2 

High 

Application does not useTLS or ignores cert errors 

2 

Password stored insecurely 

4 


— NO MEDIUM OR HIGH — 

12 


— NONE OFTHE ABOVE — 

0 
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Top 5 Suggestions parto,nccBro ^ 

• Use TLS certificate pinning 

• We rely on it, take extra steps to ensure it's reliable 

• Store credential components only in keychain 

• Especially password or session tokens 

• If possible, avoid storing the password 

• Always use strong hash generation (PBKDF2, HMAC) 

• Take steps to avoid cache / cookie leakage 

• If possible, use one-time (nonce/timestamp) tokens 

• Even better, tie to hash of request 
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Future work p arto,nccorou p 

• Wider survey 

• More formal study of broader cross section 

• Or possibly focus on one or two app types 

• May be difficult if you need $$ accounts (banks, etc.) 

• Other surveys 

• General security issues 

• Third-party data collection (analytics, crash reporting) 

• Third party support services (cloud storage, etc.) 


More detailed "best practices" recommendations 
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Thanks! 
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